EnigmA Amiga Run 1995 November/EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso/earcd/program/amos/amoslist.lzh/AMOSLIST/[e-mail]_Mon Sep 18 12:00:19 1995.msg

Internet Message Format | 1995-10-02 | 12KB

Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id MAA16288;  for <[e-mail]> ; Mon, 18 Sep 1995 12:00:18 -0400
Received: (from daemon@localhost) by svcs1.digex.net (8.6.12/8.6.12) id JAA14703 for amos-out; Mon, 18 Sep 1995 09:16:20 -0400
Received: from mail1.access.digex.net (mail1.access.digex.net [205.197.247.2]) by svcs1.digex.net (8.6.12/8.6.12) with ESMTP id JAA14700 for <[e-mail]>; Mon, 18 Sep 1995 09:16:19 -0400
Received: from mail.fwi.uva.nl ([e-mail] [146.50.4.20]) by mail1.access.digex.net (8.6.12/8.6.12) with ESMTP id JAA24897;  for <[e-mail]> ; Mon, 18 Sep 1995 09:16:15 -0400
Received: from ow40.fwi.uva.nl
          by mail.fwi.uva.nl with ESMTP (sendmail 8.6.12/config 5.13).
          id PAA21153; Mon, 18 Sep 1995 15:14:10 +0200
Received: from localhost
          by ow40.fwi.uva.nl (sendmail 8.6.12/config 5.12).
          id PAA00340; Mon, 18 Sep 1995 15:15:39 +0200
Message-Id: <[e-mail]>
Date: Mon, 18 Sep 1995 15:15:39 +0200
From: [e-mail] (Jan Lubbers)
X-Organisation: Faculty of Mathematics, Computer Science, Physics & Astronomy
                University of Amsterdam
                Plantage Muidergracht 24
                NL-1018 TV Amsterdam
                The Netherlands
X-Phone:        [phone]
X-Fax:          [phone]
To: [e-mail]
Content-Length: 9858
Status: RO
X-Status:

The Amos Game Group (TAGG = suggested name)

Hello fellow members of the group!

I would like to discuss some aspects of group coding with you. I have just
noticed this text has become increasingly large, I hope I don't break any
mail-limits ;-)

I'll try and write something about the organisation/management of the
group. Some things may sound familiar, but I've just included them here for
a good overview, so please hang on. At the end of the text I've supplied a
short info about my Amiga and my skills.

I have asked myself the following questions and have come up with some
answers too, but if you have the same or a different opinion on a subject, you couldn't please me more if you commented on it.

- Why did we form a group?
  When Ben Wyatt suggested we could form a group, many persons on the
  list loved that idea and consequently joined the group. Working together
  we could make a big, polished and high quality game, which none of us
  could ever make on his own.

- What possible advantages does a group have?
  In the early days, games looked and sounded awfull (with a few
  exceptions). The reason for this was that the programmer often had to
  draw the gfx and compose the music himself. Nowadays, software houses
  employ skilled and talented artists to do just this.
  Lone wolf developers however, (I think most people on the Amos list fall
  into this category)- albeit being very persistant and creative- simply
  cannot be expected to be an expert coder as well as a talented artist.
  Neither can they be expected to code a full engine in their spare time,
  although sometimes this is done.
  The most succesfull "bedroom programmers" are "utility coders", because
  they focus all their efforts to develop a highly specialised, but limited
  (in the sense of restricted to one particular use) product. Often they
  keep updating and enhancing their program through the years.
  Just think of the numerous Amos extensions for example: it's the coding
  that counts, not the absent music or gfx.
  Also, think of the famous demo groups, some persons in it are brilliant
  when it comes to algorithms but can't draw any better than the average   kindergarten kid (I can, but that makes my musicality even worse! :-),
  yet together with their artistic members, they make a brilliant demos!

- What disadvantages could a group have?
  The biggest problem in all cooperation is communication!
  Communication should always be clear and I think everyone should express
  their feelings any time, _whatever_ they are.
  Somewhere, sometime everyone will have to compromise a little.
  I shall try and explain what this could mean for our game. For quality
  sake, we'll want CONTINUITY in our game. This is a _very_ important
  aspect: the game (whatever it will be) should be conceived as a whole,
  and not just some brilliant ideas/modules/(sub)games/gfx/musix/sfx thrown
  together. Sometimes, something just doesn't "fit in".
  So interpersonal *giggle* communication plays a large role in group
  efforts. We should communicate as much as possible, especially now,
  in the beginning of our embarkment. I propose that we'll do some wild and
  provocative brainstorming about everything for at least a couple of
  weeks.

  Note also that language may become a slight problem
  if people can't express themselves as much and as precise as they want
  to. I think people should be given the freedom to talk -in detail- about
  a spectacular new and breathtaking DOOM-like game. The game may or may
  not be implemented eventually (probably not, because it's next to
  impossible to do - even in assembly), but THINKING about that or any
  other _type_ of game offers a different view at gameplay aspects.
  For instance, many of the ideas used in one type of game can INDEED
  effectively be exploited in a totally different type of game!

  Furthermore, we have the problem of exponential complexity. Exponential?
  Yes. Because all information has to go from each member of the group to
  each other member. Each member may have a totally distinct opinion of
  any other member, and it wouldn't be more than normal if he gave his
  comments too.

- How do we organise our group?
  Well, this depends of lot on what kind of game we're going to make.
  If we'll make a graphical adventure, we'll need good plot writers too,
  but if we'll make an action game we'll be more in need of people who
  know how to optimise their code. Other (less experienced) coders could
  learn a lot from constructing less time-critical programs like the
  development tools (eg: advanced map editors with attribute-tiles).
  People who want to, may be able to work under supervision of an
  experienced coder, etc.

- How do we appoint tasks to members?
  Golden rule: never do anything you pertinently don't like!
  Maybe it's better to do nothing at all, than to work on something for
  weeks/months without getting _any_ satisfaction from it. After all, we're
  supposed to have a lot of fun participating in this group, otherwise why
  bother?

- Who has experience with working in groups?
  Anyone who has any relevant experience, please inform us.

- Who has management experience?
  Managing our group may become a difficult and time consuming task.

- How many persons do we need?
  Theoretically speaking at least two, otherwise we wouldn't be a group :-)
  On a more practical view, I think we could get away with as little as
  four people (design/coding/music/gfx). This really depends a lot on the
  type of game we're going to make, so while thinking about this, let's
  not commit to anything YET.
  Another important bound is the maximum number of participants. Too many
  persons make a project unwieldy, especially if they're not professionally
  organised. Let's face it: we're not a company. I estimate the maximum
  number of active members for ONE game to lie in the range of 6-12.
  I don't remember how many persons are actually in the group, was it 18 or
  so? This is obviously too much for one game, so we could opt for a split.

- What kind of talent do we need?
  I'm just listing possible subjects:
  Game concept / Game design / Mechanics / Research & Ideas / Plot
  Overall design / Continuity & Style
  Algorithm design / Pseudo Code / Prototyping / Module definition
  Coding / Optimising / Embedded assembly / Debugging *yuck* / Testing
  GFX / Animation / Level design
  Music / SFX
  Any suggestions?

- Who do we plan a schedule?
  This will be of later concern, but we mustn't forget it, so I'll mention
  it now.

- What development machine?
  We need at least one person with a big harddisk and a lot of memory,
  let's call him the PRODUCER.
  IMPORTANT:
  I suggest that the producer keeps all latest versions of all files.
  Whenever someone is in need of some gfx, algorithm, etc. he can contact
  the producer, who will then give it to him. Of course, all latest
  versions should be given to the producer too.
  In the end, the game can (but does not have to) be put together on his
  machine.

- Which target (machine/processor/memory)?
  68000/1mb or better (remember it's a game, not an application)

GAME:
- What game-type should we choose?
  What do WE like and what do OTHER amiga gamers like?
  What can we actually achieve? What is best suited for group development?
  How do we vote?

- A bored idea:
  Let's make an ESCOM/AT game. No, don't laugh, I'm serious. What I just
  thought of is that AT may need some promotion. A promotional game,
  something new, something wild. Something to celebrate the Amiga's
  rebirth! Uh.. never mind, the game will not be finished within the next
  few months anyway.

SYSTEM:
amiga 2000 / 1mb chip / ks1.3 (old, eh? not to mention obsolete)
stereomaster sampler

SOFTWARE:
octamed v3
amos 1.36 / compiler
amos pro 1.12 AF coverdisk

TIME:
As much as I can afford to spend, which will vary from week to week.
Currently, this will be around 7 hours a week.

SKILLS:
assembly, basic, c, modula, pascal, prolog, amiga-dos, ms-dos, unix

I like/am good at:
  Game concept / Game design & Mechanics / Overall design
  Algorithm design & Pseudo Code / Prototyping (Hey, that's what Amos is
  made for :-)

Big no-no's (ANTI-SKILLS):
  Music
  Animation

A bit off topic:
I'll now tell something about a group project I've been involved in.
I hope this case description can help us.
I'm a student of Artificial Intelligence at the University of Amsterdam in
the Netherlands. Last year I've implemented a module of a full controller
for a 6 DOF robot that had to play a game of chess against a human.
This module was concerned with planning the movement path, the conversion
of board to real-world coordinates and updating the board.
This was my first big C (pun not intended :-) project and the results were
surprisingly good, in particular because of the modular approach we used.

The robot control was divided into three sub-groups, each consisting of
two programmers.
1. image processing (video camera grabs a picture of the board)
   module: isolate the human chess-move made, pass-thru to path-planner

2. path-planner
   module: plan path for computer move, calculate path
   pass-thru the path in real world coordinates to inverse kinematics

3. inverse kinematics
   module: from a given path, calculate the sequence of joint angles
   for each of the joints.
These joint angles were fed to the robot, which in turn moved the pieces.

The groups worked independly(!) of each other for a period of 3 months,
after having agreed on the information-flow between the modules in the
first week. During the last week, all three modules were brought together
and needed only minimal (cosmetic) changes.

Thanks for reading this somewhat tedious text (I'm not a novelist, you
know ;-)

-Jan Lubbers (member of TAGG, or whatever you prefer to call it ;-)